Because of the peculiar evolution of Intel architecture personal computers, there has been a continuous need for the operating system to support what is now known as a "Real Mode" environment. The first 8088 series microprocessors were designed to utilize operating or random memory of up to 1024 Kilobytes. While this constraint was not originally seen as a significant limitation, subsequent increases in computing power of subsequent generation processors have increased the need for greater memory. Since the development of the 8088 architecture, a variety of methods have evolved to provide access to such extra memory. With the advent of the 286 series microprocessor, "protected mode" became available as part of the central processing unit (CPU)'s architecture, and a method for switching back and forth between real and protected modes was provided in the basic input/output system (BIOS) provided with the system. Vendors used this mode switching capability to create "DOS Extender" programs that allowed an application to run in protected mode and then switched back to real mode to perform system related operations such as I/O and file management. When operating in the Protected Mode, a series 286 processor was able to increase the amount of memory available to 16 megabytes. Such additional memory was called extended memory.
The advent of the 386 series microprocessor architecture with paging capabilities and "Virtual 8086" (V86) Mode, saw the advent of "memory management" programs that provided the paging capability to real mode programs. These programs, part of a class called V86 Mode Monitors or Virtual Mode Monitors (VMMs), operate the system in protected mode and provide certain services to one or more V86 mode environments. These services typically consist of memory management services, but VMMs exist for multi-tasking (Microfsoft's Windows), providing debugging capabilities (Nu-Mega Technologies' Soft-ICE) and various other uses.
Since Intel architecture provides for only a single protected mode environment or VMM to be active at any one time, the VMMs and DOS Extenders were thus unable to co-exist, and a group of vendors of the two technologies united and provided the Virtual Control Program Interface (VCPI). This Application Program Interface (hereinafter "API") provides DOS Extenders the ability to switch the protected mode environment to and from the VMMs, allowing the DOS extenders to function much as they did in the 286, BIOS switched environment, but with the VMM switching in and out of the DOS Extender's environment rather than the BIOS.
The pressure on the real mode address space was not fully relieved, however. Neither the paging capability provided by memory manager VMMs, nor the application relief provided by DOS Extenders, was sufficient to meet users needs for real mode address space, and in late 1989 Helix Software Company of New York developed Netroom, a product that used the paging capability of the 386 to multi-task certain layers of the operating system in a manner similar to overlay technology found in more sophisticated operating environments, such as expounded in U.S. Pat. No. 3,618,045 to Campbell. In July of 1991 Quarterdeck Office Systems of California used a similar technology to overlay the BIOS with Real Mode addressable RAM. These techniques are limited in that by using paging and overlay techniques they can place a substantial drain on performance. They also limit the address space of the drivers and other resident software that they manage to the size of the overlay region which, of course, is at most, limited to the 1 Mb V86 address space, and in practice is substantially smaller.
With the advent of Microsoft Windows, Microsoft needed a method that would allow DOS Extenders to coexist with Windows, and thus developed the DOS Protected Mode Interface (DPMI), Intel Corporation document 240977-001, which is actually the API for the DOS Extender that is built into Microsoft Windows. Thus, existing DOS Extender programs could perform simple translations on behalf of the applications, allowing them to operate in a Windows controlled environment.
DOS Extender companies have also provided Protected Mode capabilities to operating system level software such as device drivers and resident software (collectively "drivers"). This technology has the advantage of not limiting the address space of the drivers. However, DOS Extender methodology has significant drawbacks when used in a driver environment. First, each driver must have its own DOS Extender, creating multiple environments that must be supported. Second, since DOS Extenders run in their own protected mode environment, several useful capabilities such as having universal and immediate access to interrupts, are not available. In addition, DOS Extender technology is based upon switching from one protected mode environment to another. This switching has inherent CPU overhead which makes it substantially slower than desired for operating system level software that may be required to respond very quickly, in "real time".
U.S. Pat. No. 4,974,159 to Hargrove, et al. describes a method for transferring control to protected mode from Virtual 8086 mode using a faulting mechanism. This method is convenient in that it requires only one byte of code in the V86 instruction space, and can be used to transfer control to a dispatcher that can then call protected mode routines, simulate some V86 function or return from a call to a V86 routine. However, this mechanism has several drawbacks when considered for use in an environment in which drivers or resident software is running in protected mode. First, the faulting mechanism involved is slow, requiring a CPU fault (error condition) to switch modes. Second, the processing of the fault is inherently slow because the instruction causing the fault must be examined to determine the cause of the fault. Also, the mechanism for dispatching from the fault handler requires data structures which associate a particular fault location with a particular protected mode routine. This causes either a fixed limit to the number of such faults that can be handled (as is the case in Microsoft Windows), or requires a complex allocation scheme to allow for the dynamic creation of such structures.
Finally, in order for any protected mode drivers to be truly useful they must be able to operate with Microsoft's Windows (hereinafter simply "Windows") and other multi-mode operating environments. The obvious approach to this problem, which has been taken by DOS Extender vendors, is to maintain a separate environment as they do in the DOS Extender/VMM arena, and since Windows does not contain a VCPI-like interface of its own when Windows starts up its environment, write a Windows device driver that transfers control over from the Windows Global Descriptor Table (GDT) and Interrupt Descriptor Table (IDT) to the protected mode GDT/IDT that the DOS-Extended software operates on, much like VCPI provides.
This approach is similar to VCPI and has many of the same drawbacks as VCPI itself, namely, it is slow, does not allow for some particularly useful capabilities as discussed earlier, and is difficult to implement. It has the additional drawback in a Windows environment of conflicting with Window's internal faulting mechanism, requiring several VCPI-like switches for each event causing a fault.